\chapter{Mobilité: adapation aux clients nomades et gestion du déploiement}

\section{Adaptation de l'interface XWiki aux terminaux mobiles}

\subsection{État de l'art}
L'iPhone, contrairement à beaucoup de smartphones, supporte l'affichage sur son petit écran des pages Web d'une façon très astucieuse. Apple a en effet mis beaucoup d'ingéniosité dans la conception du navigateur de son appareil. Il s'agit d'une méthode tout à fait satisfaisante pour un usage occasionnel, cependant on peut observer que beaucoup de sites qui misent sur l'aspect mobilité et souhaitent être fréquemment utilisés mettent des moyens pour concevoir une interface réellement adaptée à l'iPhone, de façon à donner à l'utilisateur une ergonomie optimale.

\begin{figure}
  \centering
  \includegraphics[width=0.5\textwidth]{figures/iphone.jpg}
  \caption{iPhone}
  \label{fig:iphone}
\end{figure}

Deux exemples nous ont particulièrement inspirés dans notre travail : \textit{Facebook} et \textit{Google}. Ces deux sites Web ont souhaité s'intégrer le mieux possible à l'interface de l'iPhone, de façon à se fondre dans son environnement. Ils sont utilisé les concepts et habitudes propres à cette plate-forme particulière, avec notamment une barre de menu réduite, l'utilisation de technologies dynamiques, la mise en avant des fonctionnalités les plus utiles, et bien sûr une utilisation plus rationnelle de l'espace d'affichage réduit.

\subsubsection{Facebook}

La version spécialement dédiée à iPhone de Facebook est probablement le meilleur exemple d'adaptation à la plate-forme. Elle met en avant les quatre fonctionnalités les plus fréquemment utilisées : \textit{Home} (la page de résumé de tout ce qui s'est passé récemment sur Facebook), \textit{Profile} (sa propre page de profil), \textit{Friends} (les événements des amis) et \textit{Inbox} (les mails reçus, avec une indication de nouveau messages par un badge coloré).

\begin{figure}
  \centering
  \includegraphics[width=0.6\textwidth]{figures/facebook.jpg}
  \caption{Facebook}
  \label{fig:facebook}
\end{figure}

Chacun de ces quatre onglets est lui-même pourvu de trois sous-onglets, afin de ne pas encombrer l'espace ; ainsi :
\begin{itemize}
\item[Home] comprend les sous-onglets \textit{News Feed} (les infos des amis), \textit{Events} (les prochains événements du calendrier) et \textit{Requests} (les demandes d'ajouts à la liste d'amis)
\item[Profile] comprend \textit{Info} (informations basiques), \textit{Wall} (le "mur" de commentaires) et \textit{Photos} (ses albums photos)
\item[Friends] comprend \textit{Status} (liste des statuts des amis), \textit{Online} (pour voir qui est en ligne) et Photos (derniers albums mis à jour). Une tape permet d'accéder au profil ou aux albums.
\item[Inbox]  présente les mails reçus les uns après les autres, chacun avec le titre et quelques lignes. Une tape dessus permet d'accéder au contenu intégral par chargement dynamique. La barre de sous-onglets présente les trois fonctionnalités \textit{compose}, \textit{sent} et un bouton très futé, \textit{edit}, qui est en réalité une bascule (\textit{toggle}) transformant le comportement de la liste de mails de manière à pouvoir les modifier (essentiellement, les effacer).
\end{itemize}

On navigue entre ces différents onglets entièrement par recours à la technologie Ajax qui permet de ne charger que la partie de la page qui est différente. De plus, cette interface fait un usage très intelligent de l'espace puisqu'elle permet d'accéder par deux boutons placés dans la barre de titre à deux fonctions pratiques, qui doivent rester discrètes mais immédiatement accessibles quand on en a besoin : la modification de son propre statut et la recherche.

\subsubsection{Google}
Lorsque l'on visite Google depuis un iPhone, on se trouve présenté un menu de différents services : \textit{home} (le recherche web classique), Gmail, Calendar, Reader et More (qui donne accès à une page recensant tous les autres services Google : Docs, sms, news, picasa, blogger...). On remarque ainsi que Google a identifié les services les plus susceptibles d'intéresser un utilisateur nomade : le mail, l'agenda et la lecture de flux rss correspondent aux usages les plus fréquents, ceux qu'on souhaite pouvoir consulter à tout instant sur un petit appareil de poche. Google maps et YouTube ne figurent pas parmi les services proposées puisqu'ils disposent déjà de leurs propres applications natives dédiées.

\begin{figure}
  \centering
  \includegraphics[width=0.6\textwidth]{figures/google.jpg}
  \caption{Google}
  \label{fig:google}
\end{figure}

Chacun de ces différents services voient leur affichage adapté selon les mêmes principes :
\begin{itemize}
\item[Gmail] les mails sont listés les uns après les autres, chacun avec l'objet et les premiers mots, comme dans la version originale mais sans la barre latérale dont les fonctionnalités sont reprises dans des sous-barres de menus. Trois fonctionnalités sont immédiatement accessibles : \textit{archive} et \textit{delete} d'une part, qui s'appliquent au mail sélectionné par la case à cocher affichée en face de chaque mail, et \textit{compose} d'autre part.
\item[Calendar] les différents événements sont listés les uns après les autres, regroupés par date.
\item[Reader] les billets sont listés les uns après les autres, chacun avec le titre et quelques lignes. Une tape dessus permet d'accéder au contenu intégral par chargement dynamique.
\item[More] les autres services sont disposés sous forme d'icônes facilement identifiables.
\end{itemize}


\subsection{Description de la démarche}

Suite à cette étude des interfaces iPhone, nous avons commencé à esquisser celle que nous voulions donner à XWiki. Il a d'abord fallu choisir ce qu'il fallait laisser à l'écran. Les fonctionnalités telles que "Imprimer" ou "Exporter en PDF" n'étant d'aucune utilité sur un iPhone, elles ont été les premières à passer à la trappe.

Lorsque l'on souhaite accéder à XWiki au moyen de son iPhone, c'est d'abord pour consulter un document : l'espace principal doit être constitué du corps du document, consultable librement. On doit également pouvoir accéder facilement à l'historique, aux commentaires et pièces jointes éventuelles, ainsi qu'à la fonctionnalité d'édition : ces quatre commandes constitueront les accès directs à partir de la barre de menus. %, tandis que les commandes moins fréquemment utilisées seront accessibles au moyen d'un menu "More" du même type que celui de Google.
Ce menu changera lorsque l'on passera de l'action de consultation à l'action d'édition : il faudra alors pouvoir accéder aux différents modes d'édition.
Enfin, les actions à portée générale, au niveau de l'application dans son ensemble, seront accessibles depuis la barre de titre, à la manière de Facebook.

\subsubsection{Le framework \textit{iUI}}
L'auteur de l'interface de Facebook a mis son savoir-faire à disposition des développeurs en concevant un framework CSS+Javascript facilitant la conception d'interfaces pour iPhone. Nous avons pris ce framework comme cadre à la réalisation de la skin XWiki pour iPhone, ce qui a permis de profiter d'effets intéressants du type de ceux de Facebook.

\begin{figure}
  \centering
  \includegraphics[width=0.6\textwidth]{figures/iui.png}
  \caption{iui}
  \label{fig:iui}
\end{figure}

Cependant, contrairement à Facebook ou Google, nous ne souhaitions pas modifier le code du cœur de XWiki, mais seulement écrire une skin qui ne modifierait que l'affichage et non le comportement de l'application. Ainsi, nous avons renoncé à modifier les liens produits en fonction du contexte, et ce d'autant plus que par conception un wiki peut contenir des liens vers n'importe quelle page, laquelle peut par ailleurs être envoyée par mail, enregistrée dans les signets ou tout autre moyen qui ne permettrait pas de contrôler le contexte dans lequel la page est appelée. De ce fait, nous avons dû abandonner les fonctionnalités sympathiques de chargement dynamique par Ajax offertes par iUI.

\subsubsection{L'écriture de la skin}
La question à se poser était à partir de quoi construire cette nouvelle skin. L'une des faiblesses de la version actuelle de XWiki est le manque de clarté du code des skins. Cela fait partie des points à améliorer en priorité pour les prochaines versions mais en attendant il fallait comprendre comment fonctionnait le modèle se skin et en produire une beaucoup plus simple et épurée que la skin par défaut (appelée \textit{albatross}).

\begin{figure}
  \centering
  \includegraphics[width=0.6\textwidth]{figures/dodo.jpg}
  \caption{dodo}
  \label{fig:dodo}
\end{figure}

\begin{figure}
  \centering
  \includegraphics[width=0.6\textwidth]{figures/albatross.jpg}
  \caption{albatross}
  \label{fig:albatross}
\end{figure}

L'une des anciennes skins, nommée \textit{dodo}, présentait l'avantage d'avoir une interface moins complexe que la skin \textit{albatross} et nous avons donc commencé à travailler à partir de ce code en le modifiant. Toutefois il est vite apparu qu'il contenait du code trop ancien et parfois démodé. Cette expérience nous ayant en revanche permis de nous familiariser avec l'écriture d'une skin, nous avons repris l'écriture à zéro, en partant d'une feuille blanche et en piochant au besoin l'inspiration dans les skins \textit{albatross} et \textit{dodo}. Ceci a permis d'obtenir un modèle plus propre, d'autant plus qu'XWiki offre cet avantage de se replier sur les composants de la skin \textit{albatross} lorsqu'il ne le trouve pas dans la skin courante, ce qui offre une certaine souplesse.

Par ailleurs, ne disposant pas d'un iPhone mais seulement d'un PC sous Linux, les développements ont été effectués avec Firefox et un navigateur rudimentaire fondé sur WebKit, le moteur utilisé dans Safari et sur l'iPhone. Un iPod touch a été commandé et est en attente de livraison.

\subsection{Description de la skin}

La skin pour iPhone se présente de la façon suivante : en haut, une barre de titre, avec le nom de l'application (XWiki) ; une tape au centre de la barre de menu permet à tout moment de revenir à l'accueil, quel que soit l'endroit où on se trouve.

Cette barre de menus comprend également deux zones d'actions : une pour les actions d'annulation, en haut à gauche ; et l'autre, en haut à droite, étant un bouton donnant accès aux actions à portée générale.

En-dessous de la barre de titre se trouve la barre de menus, qui change en fonction du contexte : visualisation ou édition. Puis, le corps du document.

\begin{figure}
  \centering
  \includegraphics[width=0.6\textwidth]{figures/accueil.jpg}
  \caption{Accueil}
  \label{fig:accueil}
\end{figure}

\subsubsection{Accueil et interface de visualisation}

Le document qui est présenté est celui de la page d'accueil. Il est évidemment possible de taper sur les liens pour se rendre sur d'autres documents : ceux-ci s'ouvrent de la même façon, seul le contenu change. Comme nous n'avons pas utilisé la fonctionnalité de chargement dynamique par requêtes asynchrones Ajax, la page qui est appelée est entière et on peut y accéder directement par son URL.

Le menu qui est présenté comprend les fonctions suivantes : Éditer, Historique, Commentaires (avec affichage du nombre de commentaires), Pièces jointes (avec affichage du nombre de pièces jointes). Quand on tape sur l'une des trois dernières actions, la fonctionnalité apparaît et la zone de menu correspondante change en l'action de revenir à la visualisation. Lorsqu'il n'y a pas de commentaire ou de pièce jointe, un formulaire permettant d'en ajouter est proposé dans la page adéquate.

\begin{figure}
  \centering
  \includegraphics[width=0.6\textwidth]{figures/historique.png}
  \caption{Historique}
  \label{fig:historique}
\end{figure}

\begin{figure}
  \centering
  \includegraphics[width=0.6\textwidth]{figures/commentaires.png}
  \caption{Commentaires}
  \label{fig:commentaires}
\end{figure}

\begin{figure}
  \centering
  \includegraphics[width=0.6\textwidth]{figures/piecesjointes.png}
  \caption{Pièces jointes}
  \label{fig:piecesjointes}
\end{figure}

\subsubsection{Interface d'édition}
Une tape sur "Éditer" permet d'éditer le document en cours. Le menu change alors pour donner accès aux différents modes : wiki, wysiwyg, objets, classes, droits d'accès, historique. Bien entendu, il n'y a pas la place pour placer ces actions au même niveau. On a donc recours à des sous-menus.

\begin{figure}
  \centering
  \includegraphics[width=0.6\textwidth]{figures/editer.png}
  \caption{Editer}
  \label{fig:editer}
\end{figure}

La plupart du temps, l'utilisateur voudra simplement amender le contenu du document. Les actions à placer en avant sont donc celles qui correspondent aux modes wiki et wysiwyg. Comme le premier espace de la barre est réservé au retour à la visualisation, il ne reste plus qu'un emplacement, celui situé à droite, qui constituera le sous-menu "avancé" contenant le reste des actions.

\subsubsection{Actions à portée générale}
Les actions de portée générale sont accessibles, nous l'avons dit, à partir du bouton situé en haut à droite, dans la barre de titre. Elle présente les fonctionnalités qui ne dépendent pas du document, telles que "Rechercher", "Se connecter", "S'enregistrer" ou, lorsqu'on est connecté "Profil" et "Se déconnecter".

\begin{figure}
  \centering
  \includegraphics[width=0.6\textwidth]{figures/rechercher.png}
  \caption{Rechercher}
  \label{fig:rechercher}
\end{figure}


Une tape sur "Rechercher" provoque l'affichage, par-dessus le document, d'un champ de recherche constitué graphiquement d'une extension de la barre de titre, de façon très élégante. Un bouton annuler situé en haut à gauche permet de cacher à nouveau ce formulaire. Lorsqu'on valide l'entrée, la recherche est effectuée et les résultats sont présentés à l'utilisateur.

\begin{figure}
  \centering
  \includegraphics[width=0.6\textwidth]{figures/identification.png}
  \caption{Identification}
  \label{fig:identification}
\end{figure}

De façon similaire, une tape sur "Identifiation" permet d'afficher un formulaire d'identification. Cependant dû à des limitations techniques, il ne s'agit pas cette fois d'un recouvrement de la page mais du chargement d'une nouvelle page. L'apparence reste cependant très proche. Ici également le bouton annuler en haut à gauche permet de revenir au document. Une fois identifié, on revient là on était.

\section{Prochaines étapes}

N'ayant pas encore pu tester la skin sur un vrai iPhone (ni iPod touch), il est possible que certaines fonctionnalités ne fonctionnent pas comme attendu. L'une des étapes à venir consistera à corriger les erreurs résiduelles. Par ailleurs, les retours de la part des utilisateurs de XWiki dans le contexte des cas d'utilisation OW2, Mandriva, et XWiki.com seront pris en compte pour adapter l'interface aux besoins et critiques qu'ils exprimeront. L'ergonomie de certaines fonctionnalités sera encore améliorée; par exemple l'affichage des résultats des recherches sera adaptée à la petite taille de l'iPhone.
 

\section{Gestion du mode déconnecté}
 
 En plus d'adapter l'affichage d'XWiki aux terminaux mobiles, le projet XWiki Concerto vise à fournir aux utilisateurs de terminaux légers de type Blackberry, tablettes ou petits ordinateurs portables, une version d'XWiki capable de fonctionner en environnement totalement déconnecté, ou déconnecté par intermittence. Ce mode de fonctionnement met en oeuvre les composants des lots SP1 pour la gestion des sessions, SP2 pour l'adaptation au terminal, et SP3 pour la gestion de la sécurité de la connexion au réseau P2P et des messages et opérations diffusés sur le réseau.
 
 Une version d'XWiki a été développée spécifiquement pour fonctionnement en mode déconnecté: XWiki Eclipse\footnote{\url{http://code.xwiki.org/xwiki/bin/view/Extensions/XEclipseExtension}}. Elle repose comme son nom l'indique sur la plateforme applicative Eclipse, plus précisément Eclipse Rich Client Platform (Eclipse RCP\footnote{\url{http://www.eclipse.org/rcp/}}, un framework générique pour réaliser des applications "client riche", massivement utilisé dans l'industrie (e.g. la NASA, JP Morgan...). La figure~\ref{fig:xeclipse} représente l'application en fonctionnement. 
 
\begin{figure}
  \centering
  \includegraphics[width=0.7\textwidth]{figures/xeclipse-rcp.png}
  \caption{XWiki Eclipse}
  \label{fig:xeclipse}
\end{figure}
 
L'application propose les fonctionnalités suivantes:
\begin{itemize}
\item travail en mode déconnecté
\item assistants de création de page
\item assistant de création de connexion
\item possibilité de disposer dans la même application de plusieurs wikis
\item téléchargement complet d'un ou plusieurs espaces ("grabbing")
\item rafraîchissement d'espaces
\item création d'espace
\item mise en garde lors de conflit d'édition
\item possibilité de définir des "working sets", tel qu'illustré par la figure~\ref{fig:workingset}
\end{itemize}

\begin{figure}
  \centering
  \includegraphics[width=0.7\textwidth]{figures/workingset-wizard.png}
  \caption{XWiki Eclipse -- Création d'un "working set"}
  \label{fig:workingset}
\end{figure}
    
 
\subsection{Eclipse embedded RCP (eRCP)}

Le projet Eclipse eRCP~\footnote{\url{http://www.eclipse.org/ercp/}} vise à adapter la plateforme Eclipse RCP aux terminaux mobiles. eRCP consiste en un ensemble de composants sous-ensemble des composants RCP. Il permet de répliquer le même modèle d'application utilisé sur un poste de travail sur des terminaux mobiles. eRCP repose sur eSWT, des composants graphiques pour appareils de petite taille. Les grands éditeurs de matériel de télécommunication mobile comme Nokia et d'autres sont impliqués dans l'initiative eRCP. 

L'équipe XWiki Concerto propose d'adapter l'application XWiki Eclipse aux appareils mobiles via le framework Eclipse eRCP. Des expérimentations vont être menés lors du premier trimestre 2008 et XWiki Eclipse sera adapté à plusieurs appareils mobiles dans le courant de l'année 2008.

La figure~\ref{fig:eswt} présente eSWT en fonctionnement sur un terminal Nokia (figure tirée de la présentation de eSWT par Gorkem Ercan lors de l'Eclipse Summit Europe 2007~\footnote{\url{http://www.eclipse.org/ercp/docs/EclipseSummiteSWT.pdf}}).

\begin{figure}
  \centering
  \includegraphics[width=0.7\textwidth]{figures/eswt.png}
  \caption{eSWT en action}
  \label{fig:eswt}
\end{figure}
    

\subsection{Gestion des sessions}

Le protocole de création de copies et de gestion des sessions lors du mode déconnecté a été prototypé dans XWiki Eclipse. Il consiste à mettre en place un cache avancé dans le réplicat local XWiki, et à générer des estampilles locales qui sont ensuite diffusées dans le réseau lorsque le noeud se reconnecte. 
 
\subsection{Déploiement et mise à jour}

XWiki Eclipse repose sur le modèle de composants OSGi\footnote{\url{http://www.osgi.org}}. Ce modèle inclut des mécanismes standards de gestion de dépendances entre composants et de mise à jour de composants, y compris sans redémarrage de l'applicatif. Le déploiement de XWiki Concerto "offline" reposera sur le standard OSGi, laissant la possibilité aux utilisateurs de télécharger et d'installer strictement ce dont ils ont besoin, dans la version qu'ils souhaitent. Les utilisateurs pourront par exemple choisir entre les composants XWoot ou SB-LTR suivant le contexte d'utilisation. Ils pourront également choisir le type de base de données à utiliser sur l'appareil mobile: fichiers plats, base MySQL Lite, Derby etc. La gestion du déploiement et des mises à jour de composants sera opérationnelle dans les versions à venir des prototypes XWiki Concerto (août 2008, janvier 2009 et suivants). 

